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Abstract: Overnight, Apple has turned its hundreds-of- 
million-device ecosystem into the world’s largest crowd- 
sourced location tracking network called offline finding 
(OF). OF leverages online finder devices to detect the 
presence of missing offline devices using Bluetooth and 
report an approximate location back to the owner via 
the Internet. While OF is not the first system of its 
kind, it is the first to commit to strong privacy goals. 
In particular, OF aims to ensure finder anonymity, un- 
trackability of owner devices, and confidentiality of lo- 
cation reports. This paper presents the first comprehen- 
sive security and privacy analysis of OF. To this end, we 
recover the specifications of the closed-source OF proto- 
cols by means of reverse engineering. We experimentally 
show that unauthorized access to the location reports al- 
lows for accurate device tracking and retrieving a user’s 
top locations with an error in the order of 10 meters in 
urban areas. While we find that OF’s design achieves 
its privacy goals, we discover two distinct design and 
implementation flaws that can lead to a location cor- 
relation attack and unauthorized access to the location 
history of the past seven days, which could deanonymize 
users. Apple has partially addressed the issues following 
our responsible disclosure. Finally, we make our research 
artifacts publicly available. 
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1 Introduction 


In 2019, Apple introduced offline finding (OF), a pro- 
prietary crowd-sourced location tracking system for off 
line devices. The basic idea behind OF is that so-called 
finder devices can detect the presence of other lost off- 
line devices using Bluetooth Low Energy (BLE) and use 
their Internet connection to report an approximate lo- 
cation back to the owner. Apple’s OF network consists 
of “hundreds of millions” of devices [4], making it the 
currently largest crowd-sourced location tracking sys- 
tem in existence. We expect the network to grow as OF 
will officially support the tracking of non-Apple devices 
in the future [6]. Regardless of its size, the system has 
sparked considerable interest and discussion within the 
broader tech and security communities [28, 29] as Ap- 
ple makes strong security and privacy claims supported 
by new cryptographic primitives that other commercial 
systems are lacking [51]. In particular, Apple claims that 
it cannot access location reports, finder identities are 
not revealed, and BLE advertisements cannot be used 
to track devices [35]. Apple has yet to provide ample 
proof for their claims as, until today, only selected com- 
ponents have been publicized [4, 6, 35]. 

Contribution. This paper challenges Apple’s secu- 
rity and privacy claims and examines the system de- 
sign and implementation for vulnerabilities. To this end, 
we first analyze the involved OF system components on 
macOS and iOS using reverse engineering and present 
the proprietary protocols involved during losing, search- 
ing, and finding devices. In short, devices of one owner 
agree on a set of so-called rolling public-private key 
pairs. Devices without an Internet connection, i.e., with- 
out cellular or Wi-Fi connectivity, emit BLE adver- 
tisements that encode one of the rolling public keys. 
Finder devices overhearing the advertisements encrypt 
their current location under the rolling public key and 
send the location report to a central Apple-run server. 
When searching for a lost device, another owner device 
queries the central server for location reports with a 
set of known rolling public keys of the lost device. The 
owner can decrypt the reports using the corresponding 
private key and retrieve the location. 
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Based on our analysis, we assess the security and 
privacy of the OF system. We find that the overall de- 
sign achieves Apple’s specific goals. However, we discov- 
ered two distinct design and implementation vulnera- 
bilities that seem to be outside of Apple’s threat model 
but can have severe consequences for the users. First, 
the OF design allows Apple to correlate different own- 
ers’ locations if their locations are reported by the same 
finder, effectively allowing Apple to construct a social 
graph. Second, malicious macOS applications can re- 
trieve and decrypt the OF location reports of the last 
seven days for all its users and for all of their devices 
as cached rolling advertisement keys are stored on the 
file system in cleartext. We demonstrate that the latter 
vulnerability is exploitable and verify that the accuracy 
of the retrieved reports—in fact—allows the attacker to 
locate and identify their victim with high accuracy. We 
have shared our findings with Apple via responsible dis- 
closure, who have meanwhile fixed one issue via an OS 
update (CVE-2020-9986, cf. Responsible Disclosure sec- 
tion for details). We summarize our key contributions. 


— We provide a comprehensive specification of the OF 
protocol components for losing, searching, and fin- 
ding devices. Our PoC implementation allows for 
tracking non-Apple devices via Apple’s OF network. 

— We experimentally evaluate the accuracy of real- 
world location reports for different forms of mobil- 
ity (by car, train, and on foot). We show that (1) a 
walking user’s path can be tracked with a mean er- 
ror of less than 30m in a metropolitan area and (2) 
the top locations of a user such as home and work- 
place can be inferred reliably and precisely (error in 
the order of 10m) from a one-week location trace. 

— We discover a design flaw in OF that lets Apple 
correlate the location of multiple owners if the same 
finder submits the reports. This would jeopardize 
location privacy for all other owners if only a single 
location became known. 

— We discover that a local application on macOS can 
effectively circumvent Apple’s restrictive location 
API [5] and access the user’s location history with- 
out their consent, allowing for device tracking and 
user identification. 

— We open-source our PoC implementation and ex- 
perimental data (cf. Availability section). 


Outline. The remainder of this paper is structured 
as follows. § 2 and § 3 provide background informa- 
tion about OF and the involved technology. § 4 outlines 
our adversary model. § 5 summarizes our reverse en- 


gineering methodology. § 6 describes the OF protocols 
and components in detail. § 7 evaluates the accuracy of 
OF location reports. § 8 assesses the security and pri- 
vacy of Apple’s OF design and implementation. § 9 and 
§ 10 report two discovered vulnerabilities and propose 
our mitigations. § 11 reviews related work. Finally, § 12 
concludes this work. 


2 Background 


This section gives a brief introduction to BLE and el- 
liptic curve cryptography (ECC) as they are the basic 
building blocks for OF. We then cover relevant Apple 
platform internals. 


2.1 Bluetooth Low Energy 


Bluetooth Low Energy (BLE) [19] is designed for small 
battery-powered devices such as smartwatches and fit- 
ness trackers with low data rates. Devices can broadcast 
BLE advertisements to inform nearby devices about 
their presence. The maximum BLE advertisement pay- 
load size is 31 bytes [19]. Apple heavily relies on custom 
BLE advertisements to announce their proprietary ser- 
vices such as AirDrop and bootstrap their protocols over 
Wi-Fi or Apple Wireless Direct Link (AWDL) [21, 36, 
48]. OF devices also use BLE advertisements to inform 
nearby finders about their presence [6]. 


2.2 Elliptic Curve Cryptography 


OF employs elliptic curve cryptography (ECC) for en- 
crypting location reports. ECC is a public-key encryp- 
tion scheme that uses operations on elliptic curve (EC) 
over finite fields. An EC is a curve over a finite field 
that contains a known generator (or base point) G. A 
private key in ECC is a random number in the finite 
field of the used curve. The public key is the result of 
the point multiplication of the generator G with the pri- 
vate key. The result is an X—-Y coordinate on the curve. 
The NIST P-224 curve [39], which is used by OF [6], 
provides a security level of 112 bit. 


2.3 Apple Platform Internals 


We briefly introduce the terms keychain and iCloud as 
they are relevant for Apple’s OF implementation. 
Keychain. All Apple operating systems (OSs) use 
a keychain as a database to store secrets such as 
passwords, keys, and trusted Transport Layer Security 
(TLS) root certificates. The keychain is used by sys- 
tem services such as AirDrop [48] and third-party ap- 
plications to store login information, tokens, and other 
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secrets. Every keychain item may contain a keychain 
access group. This group is used to identify which ap- 
plication can access which keychain items. Access poli- 
cies are implemented via entitlement files embedded into 
signed application binaries. A system process prevents 
the execution of processes with unauthorized entitle- 
ments, e.g., a third-party application trying to access a 
system-owned keychain item. This security mechanism 
can be disabled on jailbroken iOS devices or by deacti- 
vating macOS system integrity protection (SIP), which 
helps extracting keys and secrets used by Apple’s sys- 
tem services. 
iCloud. 
services handling online data storage and synchroniza- 


iCloud is an umbrella term for all Apple 


tion via Apple’s servers. All owner devices signed in to 
the same Apple account can synchronize themselves via 
iCloud. OF uses the iCloud keychain to share rolling 
advertisement keys across all owner devices. The syn- 
chronization is required to retrieve and decrypt the lo- 
cation reports from potential finders on any of the owner 
devices [4, 35]. 


3 Apple Offline Finding Overview 


Apple introduced OF in 2019 for iOS 13, macOS 10.15, 
and watchOS 6 [10 
without an Internet connection and promises to oper- 


]. OF enables locating Apple devices 


ate in a privacy-preserving manner. In 2020, Apple an- 
nounced to support third-party BLE-enabled devices to 
be tracked by the OF network [11] and released a pro- 
tocol specification for their integration [6]. We found 
that this public specification is incomplete concerning 
the overall OF system. Within this paper, we focus on 
our recovered specification that was partly validated by 
the accessory specification [6]. 

In the following, we give a brief overview of how 
OF works and introduce the different roles of devices. 
Fig. 1 depicts the interplay of the roles and protocols 
involved in OF. In particular, OF involves (1) initial 
pairing of owner devices, (2) broadcasting BLE adver- 
tisements that contain a rolling public key, (3) upload- 
ing encrypted location reports to Apple’s servers, and 
(4) retrieving the location reports on owner devices. The 
terminology of the roles below has been derived from the 
official documentation [6]. 

Owner devices. Owner devices share a common Ap- 
ple ID and can use the Find My application on macOS 
and iOS to search for any devices of the same owner. 

Lost devices. Devices that determine to be in a lost 
state start sending out BLE advertisements with a pub- 
lic key to be discovered by finder devices. Apple devices 


Owner device 


Apple’s servers 


(4) Download and decrypt 
Eee 


location reports 


(3) Upload encrypted A 
(1) Pair through 


initial setup ' 


(Lo 


Lost device 


locations reports 


___(2) Broadcast_ Broadcast 
T Bliewarh-advertisements. advertisements 


with public key 


Finder devices 


Fig. 1. Simplified offline finding (OF) workflow. 


are considered to be lost when they lose Internet con- 
nectivity. Third-party accessories [6] are small battery- 
powered devices that can be attached to a personal item 
and are set up through an owner device. Accessories de- 
termine to be lost when they lose their BLE connection 
to the owner device. 

Finder devices. Finder devices form the core of the 
OF network. As of 2020, only iPhones and iPads with a 
GPS module are offering finder capabilities. Finder de- 
vices can discover lost devices and accessories by scan- 
ning for BLE advertisements. Upon receiving an OF 
advertisement, a finder creates an end-to-end encrypted 
location report that includes its current location and 
sends it to Apple’s servers. 

Apple’s servers. Apple’s servers store OF location 
reports submitted by finder devices. Owner devices can 
fetch those reports and decrypt them locally. 


4 Adversary Model 


OF exposes several interfaces that might be targeted by 
attackers. In this section, we identify these potentially 
vulnerable interfaces and devise a comprehensive ad- 
versary model that will guide the rest of this paper. We 
first detail the four sub-models, summarized in Tab. 1, 
and we specify them by their assumptions, goals, and 
capabilities following [23]. Then, we motivate the sub- 
sequent analysis of OF protocols and components based 
on these models. 

First of all, we consider adversaries on either of 
f. (2)-(4) in Fig. 1). 
In particular, a proximity-based adversary has access to 
BLE advertisements (A2), and a network-based adver- 
sary can modify traffic between OF devices and Apple’s 


OF’s communication channels (c 


servers (A3). Also, we consider a zero-permission appli- 
cation running with user privileges on an owner /lost de- 
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Table 1. Adversary models considered throughout and guiding this paper. We assume that neither adversary has direct access to cryp- 


tographic secrets or can break cryptographic primitives. 


Model 


Local application (A1) 


Proximity-based (A2) 


Network-based (A3) 


Service operator (A4) 


Assumptions 


(1) User-installed application on 
lost /owner devices that is either re- 
viewed or notarized. (2) Zero-per- 
mission. (3) No privilege escalation 
exploits. 

(1) In BLE communication range 
of OF device. (2) Control one or 
more BLE transceivers to cover a 
larger area. 


(1) MitM position between Apple 
and OF devices. (2) Cannot break 
TLS. 

(1) Apple as the service provider. 
(2) Controls the OF server infras- 
tructure. 


Goals 


(1) Determine location of OF de 
vices without asking for permis- 
sion. (2) Track user by accessing 
current or historic location data. 


(1) Access location of lost de- 
vices or personally linkable data. 
(2) Track lost devices in larger ar- 
eas (e.g., shopping center or air- 
port). (3) DoS against OF service. 
(1) Access location of reported lost 
devices. (2) Identify reported de- 
vices. (3) Identify lost devices. 

(1) Locate individuals and their 
lost devices. (2) Correlate locations 
to create a social graph. 


Capabilities 


(1) Communicate with any server 
over the Internet. (2) Read/write 
files that are accessible by the user 
and not restricted through sand- 
boxing. 

(1) Track devices based on adver- 
tisement content. (2) Record and 
replay advertisements at different 
locations. (3) Fabricate new adver- 
tisements. 

(1) Redirect traffic to a different 
host. (2) Read, intercept, redirect, 
or modify traffic. 

(1) Access to all encrypted OF re- 
ports and their metadata. (2) Add, 
remove, or modify reports. 


vice that wants to infer the user’s current location. The 
application may be distributed inside or outside! of Ap- 
ple’s official app stores (A1). Finally, we also consider 
Apple as the service operator as an adversary that has 
access to all encrypted location reports and might try 
to infer any information based on the report metadata 
such as submission times and finder identifiers (A4). 
Note that Apple uses its iCloud keychain service for 
initial device pairing and key synchronization (cf. (1) 
in Fig. 1). Apple provides detailed information about its 
keychain [4], which appears to withstand professional 
forensics analyses [1]. Therefore, we assume that the 
pairing process is secure throughout this paper. 

To conduct a security and privacy analysis based 
on these models, we need to understand OF in detail. 
To this end, we reverse engineer the protocols involved 
in loosing, finding, and searching devices (cf. (2)—(4) 
in Fig. 1) in § 6. Based on our understanding of OF, 
we conduct a security and privacy analysis of the BLE 
communication (A2), the server communication (A3), 
and storage of encrypted reports and cryptographic 
keys (A1/A4) in § 8. 


1 On macOS§, applications can be distributed outside of Apple’s 
app store. Those applications are not reviewed [3]. However, 
Apple recommends submitting those application to their nota- 
rization service, which checks application for malicious code [8]. 
macOS§ displays a warning and asks for user consent before ex- 
ecuting non-notarized applications. 


5 Methodology 


Our analysis of OF required a comprehensive under- 
standing of the implemented protocols by Apple. Our 
methodology follows previous works analyzing the Ap- 
ple ecosystem [21, 36, 44, 45, 48], while providing new 
insights into the reverse engineering process. We started 
this research with the beta releases of macOS 10.15 and 
iOS 13, the first Apple OSs to support OF. During that 
time, no official documentation from Apple was avail- 
able regarding the OF design or implementation. There- 
fore, we used reverse engineering tools such as system 
log analysis, static binary analysis, and network traffic 
analysis. In addition, we implemented an OF prototype 
to validate our findings. Some of our findings, such as 
the BLE advertisement format and cryptographic prim- 
itives, were later confirmed by Apple’s specification for 
third-party accessories [6]. 

System Logging. To get a first overview of OS in- 
ternals, we used the system logging facility on macOS. 
It aggregates applications and kernel events, and can ac- 
cess the same events from a USB-attached iOS device. 
We can filter logs by process or keyword and adjust the 
log level for more verbose output. By using a special 
configuration profile [27], macOS will show logs that are 
normally redacted. On iOS, this option is only available 
with a jailbreak [14]. 

Binary analysis. We use binary analysis to under- 
stand the closed-source OF protocols. Many Apple bi- 
naries have been written in Objective-C, which uses 
message dispatch to resolve methods at runtime. There- 
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fore, Objective-C binaries include method and instance 
variable names as part of the dispatch table. This sim- 
plifies identifying interesting code paths and segments, 
e.g., those responsible for parsing BLE packets. Unfor- 
tunately, most OF code is written in the newer Swift 
programming language. Swift methods are statically 
called by their program address and, therefore, do not 
require an entry in the symbol table, i.e., the symbol 
names may be stripped by the compiler. Additionally, 
the Swift compiler adds several checks to achieve type 
safety, which clutters the compiled code and makes it 
hard to follow the program logic. However, dynami- 
cally linked frameworks and libraries must keep function 
names in the symbol table, facilitating the identifica- 
tion of interesting code segments. Furthermore, dynamic 
analysis methods aid in understanding the control flow 
and access function parameters at runtime. By hooking 
functions with a dynamic instrumentation tool such as 
Frida [40], we can, e.g., access cryptographic keys used 
by system processes as shown in [45]. 

Network analysis. We can identify a service’s proto- 
cols by monitoring network interfaces, which helps un- 
derstand the information exchange with external par- 
ties. OF uses two protocols: BLE for advertisements and 
HTTPS for server communication. To understand the 
embedded custom protocols and payloads, we rely on 
two sets of tools. For BLE, we use BTLEmap [31] to cap- 
ture all BLE advertisements. As we already know the 
basic frame format of Apple’s custom advertisements 
from related work [21, 36], we were able to identify OF 
as a new subtype. HTTPS proxies such as [50] decrypt 
HTTPS sessions by masquerading as both HTTP client 
and server and using self-signed TLS certificates. To ac- 
cess OF-related traffic, we disabled certificate pinning, 
which OF clients use for all server communication. 


6 Apple Offline Finding in Detail 


This section describes and discusses the technical details 
of Apple’s OF system. In reference to Fig. 1, we (1) ex- 
plain the involved cryptography and the key exchange 
during initial device pairing, and then explain the pro- 
tocols implementing (2) losing, (3) finding, (4) searching 
for devices. 

In short, devices and accessories in lost mode send 
out BLE advertisements containing a public key. Finder 
devices receive them, encrypt their location by using 
the public key, and upload a report to Apple’s servers. 
This results in an end-to-end encrypted location report 
that cannot be read by Apple or any other third-party 
that does not have access to the owner’s private keys. 


In the following, we explain the cryptography in use, 
the protocols involved in losing, searching, and finding 
devices, as well as a brief description of the system’s 
implementation on iOS and macOS. 


6.1 Cryptography 


OF employs ECC [6]. In the following, we explain the 
key generation and derivation mechanisms and the cryp- 
tographic algorithms used for encryption and decryp- 
tion. 

Master Beacon and Advertisement Keys. Initially, 
each owner device generates a private—public key pair 
(do, po) on the NIST P-224 curve and a 32-byte sym- 
metric key SKo that together form the master beacon 
key. Those keys are never sent out via BLE and are used 
to derive the rolling advertisement keys included in the 
BLE advertisements. 

OF makes device tracking hard by regularly chang- 
ing the contents of the BLE advertisements. In partic- 
ular, OF uses the concept of rolling keys that can be 
deterministically derived if one knows the initial input 
keys (do, po) and SKo but are otherwise unlinkable. OF 
iteratively calculates the advertisement keys (di, pi) for 
i > 0 as follows using the ANSI X.963 key derivation 
function (KDF) with SHA-256 [33] and a generator G 
of the NIST P-224 curve: 


Sk; = KDF(SK;j_1, “update”, 32) 1) 


( 
(ui, vi) = KDF(SK;j, “diversify”, 72) (2) 
p= d,*G (4) 


Equation (1) derives a new symmetric key from the last 
used symmetric key with 32 bytes length. Equation (2) 
derives the so-called “anti-tracking” keys u; and v; from 
the new symmetric key with a length of 36 bytes each. 
Finally, Eqs. (3) and (4) create the advertisement key 
pair via EC point multiplication using the anti-tracking 
keys and the master beacon key do. 

Key Synchronization. 
access the advertisement keys to download and decrypt 


All owner devices need to 


location reports. Therefore, OF synchronizes the mas- 
ter beacon keys via iCloud in a property list file en- 
crypted under Advanced Encryption Standard in Ga- 
lois/Counter Mode (AES-GCM). The decryption key for 
the file is stored in the iCloud keychain under the label 
“Beacon Store.” 

Encryption. 
a lost device contain an EC public key p;. A finder 


The BLE advertisements sent out by 


device that receives such an advertisement determines 
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its current location and encrypts the location with 
p;. OF employs Elliptic Curve Integrated Encryption 
Scheme (ECIES) that performs an ephemeral Elliptic 
Curve Diffie-Hellmann (ECDH) key exchange to derive 
a shared secret and encrypt the report [37]. In particu- 
lar, the finder’s encryption algorithm works as follows: 


(1) Generate a new ephemeral key (d’, p’) on the NIST 
P-224 curve for a received OF advertisement. 

(2) Perform ECDH using the ephemeral private key d’ 
and the advertised public key p; to generate a shared 
secret. 

(3) Derive a symmetric key with ANSI X.963 KDF on 

the shared secret with the advertised public key as 

entropy and SHA-256 as the hash function. 

) Use the first 16 bytes as the encryption key e’. 

(5) Use the last 16 bytes as an initialization vector (IV). 

) Encrypt the location report under e’ and the IV 
with AES-GCM. 


The ephemeral public key p’ and the authentication 
tag of AES-GCM are part of the uploaded message, as 
shown in Fig. 2. All location reports are identified by 
an id, which is a SHA-256 hash of p,. 

Decryption. 
crypted location reports follows the inverse of the en- 


An owner device that retrieves en- 


cryption procedure. First, the owner device selects the 
proper advertisement keys (d;,p;) based on the hashed 
p; of the location report. Second, it performs the ECDH 
key exchange with the finder’s ephemeral public key p’ 
and the lost device’s private key d; to compute the sym- 
metric key e’ and the IV. Finally, the owner can use e’ 
and IV to decrypt the location report. 


6.2 Losing 


An OF device that loses its Internet connection starts 
emitting BLE advertisements. This advertisement con- 
sists of the 224 bit (28 bytes) public part? of the adver- 
tisement key (p;), but required some engineering effort 
to fit in a single BLE packet. 
Advertisement Packet Format. 
gineer its way around the fact that one BLE advertise- 


Apple had to en- 


ment packet may contain at most 37 bytes [19, Vol. 6, 
Part B, § 2.3.1.3], of which 6 bytes are reserved for the 
advertising MAC address, and up to 31 can be used 





2 More precisely, OF only advertises the X coordinate of the 
public key, which has a length of 28 bytes. The Y coordinate is 
irrelevant for calculating a shared secret via ECDH, so the sign 
bit for the compressed format [20] can be omitted. 


Table 2. OF advertisement format (with zero-indexed bytes). 


Bytes Content (details cf. [6, § 5.1]) 


0-5 BLE address ((p;[0] | (0b11 < 6)) || p;[1..5]) 


6 Payload length in bytes (30) 
7 Advertisement type (OxFF for manufacturer-specific data) 
Company ID (0x004C) 
10 OF type (0x12) 
11 OF data length in bytes (25) 
12 Status (e.g., battery level) 
13-34 Public key bytes p;[6..27] 
35. Public key bits p;[0] >> 6 
36 Hint (0x00 on iOS reports) 


for the payload. For standard compliance, the custom 
OF advertisements needs to add a 4-byte header for 
specifying manufacturer-specific data, which leaves 27 
bytes. Within this space, Apple uses a custom encod- 
ing for subtypes used by other wireless services such as 
AirDrop [21]), which leaves 25 bytes for OF data. To fit 
the 28-byte advertisement key in one packet, Apple re- 
purposes the random address field to encode the key’s 
first 6 bytes. However, there is one caveat: the BLE stan- 
dard requires that the first two bits of a random address 
be set to 0b11. OF stores the first two bits of the ad- 
vertisement key together with the 24 remaining bytes in 
the payload to solve the problem. We depict the com- 
plete BLE advertisement packet format in Tab. 2. Apple 
confirmed the reverse-engineered specification later [6]. 

Advertising Interval. The same key is emitted dur- 
ing a window of 15 minutes, after which the next key 
pi+1 is used. During a window, OF-enabled iOS and 
macOS devices emit one BLE advertisement every two 
seconds when they lose Internet connectivity. 


6.3 Finding 


All finder devices regularly scan for OF advertisements. 
When the finder receives a packet in the OF advertise- 
ment format, it generates and uploads an encrypted lo- 
cation report to Apple’s servers. 

Generating Reports. 
lic key from the advertisement. Then, it determines its 


The finder parses the pub- 


current geolocation and creates a message that includes 
location, accuracy,? and status information (cf. green 
fields in Fig. 2). The message is then encrypted us- 





3 We assume that the accuracy value is encoded in metric me- 
ters as it matches the experimentally determined positioning er- 
ror of the coordinates in the location reports, as we show in § 7. 
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4 bytes 1 byte 57 byte 


10 bytes 16 bytes 


Encrypted location | AES-GCM authentication tag 


4 bytes 4 bytes 1 byte 


Fig. 2. Binary format of a location report. 


ing the algorithm described in § 6.1. Finally, the finder 
creates a complete location report, including the cur- 
rent timestamp (in seconds since January 1, 2001), the 
ephemeral public key d’, the encrypted message, and the 
AES-GCM authentication tag as shown in Fig. 2. 

Uploading Reports. Finder devices accumulate re- 
ports over time and upload them in batches regularly, 
possibly reducing energy and bandwidth consumption. 
During the evaluation with our test devices, we dis- 
covered that the median time from generating to up- 
loading a location report is 26min. We include the de- 
lay distribution in Appendix B. The delay can increase 
to several hours if the finder device is in a low power 
mode [7]. A finder limits the number of uploaded re- 
ports for the same advertisement key to four, most 
likely to prevent excess traffic on Apple’s servers. The 
upload is implemented as an HTTPS POST request 
to https://gateway.icloud.com/acsnservice/submit. Ev- 
ery request is authenticated to ensure that only gen- 
uine Apple devices can upload requests. Table 3 shows 
the request header containing a device identity certifi- 
cate, the signing CA’s certificate, and an Elliptic Curve 
Digital Signature Algorithm (ECDSA) signature over 
the request body. The certificates are stored in the de- 
vice’s keychain. However, the private key used for sign- 
ing is stored in the Secure Enclave Processor (SEP), 
Apple’s implementation of a trusted execution environ- 
ment (TEE) [4]. The SEP prohibits the extraction of 
the signing key but provides an interface for signing re- 
quests. We assume that the finder authentication serves 
as a form of remote attestation. However, we were un- 
able to verify this assumption due to the obfuscated 
code. The HTTPS request body is prefixed with a fixed 
header (0x0F8AEO) and one byte specifying the number 
of included reports. This limits the number of reports 
in a single request to 255. Each report consists the ID 
(SHA-256(p;)) followed by the 88-byte location report 
shown in Fig. 2. 


Table 3. HTTP request headers for uploading location reports. 


Request Header Value 


X-Apple-Sign1 Device identity certificate (base64) 
X-Apple-Sign2 SHA-256 hash of the signing CA (base64) 
X-Apple-Sign3 Device ECDSA signature (ASN.1) 


X-Apple-l- TimeZone 
X-Apple-I-Client Time 
User-Agent 


Client's time zone (e.g., GMT+9) 
Client's time (Unix) 
“searchpartyd/1 
<iPhoneModel>/<OSVersion>” 


6.4 Searching 


An owner requests reported location from Apple’s 
servers when searching for a lost device. As the adver- 
tisement keys are synchronized across all of the owner’s 
devices, the owner can use any of their other devices 
with Apple’s Find My app to download and decrypt 
the location reports. In short, the owner device fetches 
location reports from Apple’s servers by sending a list 
of the most recent public advertisement keys of the lost 
device. 

Downloading Reports. 
ing (cf. § 6.4), downloading is implemented as an 
HTTPS POST request to https: //gateway.icloud.com/ 
acsnservice/fetch. We show the headers in Tab. 4 and 


Similar to  upload- 


a truncated example body in Appendix A. The user 
authenticates with Apple’s servers using their Apple 
account in two steps. First, HTTP basic authenti- 
cation [41] is performed with a unique identifier of 
the user’s Apple ID* and a search-party-token that is 
device-specific and changes at irregular intervals (in 
the order of weeks). Second, several headers with so- 
called “anisette data” are included. Anisette data are 
short-lived tokens valid for 30s and allow omitting two- 
factor authentication from a previously authenticated 
system [2]. 

Decrypting Reports. 
load request contains a list of finder location reports 
(cf. Fig. 2) and metadata such as the hashed public ad- 
vertisement key and the time when the report was up- 


The response to the down- 


loaded. We show a truncated example of the response 
body in Appendix A. Using the respective private ad- 
vertisement keys d;, the owner device can then decrypt 
the received location reports. Apple’s Find My applica- 
tion combines a subset of the reports to display the most 





4 This numerical identifier is unique to each Apple account and 
does not change even if the user changes their primary email 
address. 
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Table 4. HTTP request headers for downloading location reports. 


Request Header Value 


Base64 encoded basic authentication 
Anisette data 
Anisette data 
Anisette data 


Authorization 
X-Apple-I-MD 
X-Apple-I-MD-RINFO 
X-Apple-I-MD-M 
X-Apple-I- TimeZone Client’s time zone 
X-Apple-I-Client Time Client’s time (ISO 8601) 
X-BA-CLIENT-TIMESTAMP. Client’s time (Unix) 
“searchpartyd /1 
<iPhoneModel>/<OSVersion>” 


User-Agent 


recent location of the lost device on a map. According to 
Apple, multiple reports are combined to get a more ac- 
curate location [4, p. 104]. While we did not reconstruct 
Apple’s algorithm, we show in § 7 that the downloaded 
location reports are sufficient to not only determine the 
most recent location but to even precisely reconstruct 
and trace the movement of a lost device. 


6.5 System Implementation 


Apple’s OF system is implemented across several dae- 
mons and frameworks which communicate via XPC, 
Apple’s implementation of interprocess communica- 
tion [12]. We depict the dependencies of the iOS imple- 
mentation in Fig. 3. The main daemon that handles OF 
is searchpartyd, which runs with root privileges. It gen- 
erates the necessary keys and performs all cryptographic 
operations. The daemon is also responsible for commu- 
nicating with Apple’s servers to synchronize keys, sub- 
mit location reports as a finder device, and fetch loca- 
tion reports as an owner device. The bluetoothd daemon 
is responsible for sending and receiving OF advertise- 
ments and passes received advertisements to locationd. 
The locationd daemon adds the device’s current location 
and forwards this information to searchpartyd, which 
generates the finder reports. On macOS, some function- 
ality of searchpartyd such as the server communication 
is externalized to the searchpartyuseragent daemon to 
support the multi-user architecture that is not available 


on iOS. 


7 Location Report Accuracy 


We experimentally assess the accuracy of OF location 
reports submitted by finder devices. This serves two 
purposes. (1) From an attacker’s perspective, we can 
determine the severity of the discovered vulnerability al- 
lowing unauthorized access to location history described 
in § 10. (2) From an end-user’s perspective, we can pro- 
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Fig. 3. Simplified view of components and their interactions such 
as apps (63), daemons (i), frameworks (%°), and drivers (*#) that 
are used by OF on iOS. We highlight the two involved external 
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vide empirical evidence on the quality of OF location 
reports when retrieving lost devices. 

Apple’s Find My application combines multiple lo- 
cation reports to improve accuracy when displaying a lo- 
cation on a map [4]. It does not show the seven-day his- 
tory of location reports that can be available on Apple’s 
servers. In this section, we assess the location report ac- 
curacy by using this historical location data. To this 
end, we use the same PoC implementation presented 
in § 10 to access the raw location reports for our own 
devices. We conduct two sets of experiments in this sec- 
tion. First, we evaluate the accuracy of OF reports for 
mobility tracking. Second, we use the seven-day loca- 
tion data history to profile a user’s most visited or “top” 
locations—which can be abused for user identification. 
We open-source all data and evaluation tools forming 
this section to make our results reproducible (cf. Avail- 
ability section). 

A Note on Geographic Coordinates. 
this section, we deal with geographic coordinates, their 


Throughout 


distances, and their projections. In order to produce 
meaningful results, we need to use coordinates in the 
same reference system. All locations in this paper are 
latitude and longitude coordinates in the World Geode- 
tic System 1984 (WGS 84) [24], which is also used by 
GPS. We apply the EPSG:3857 projection [25] to visu- 
alize coordinates on a map (e.g., Fig. 4). When we cal- 
culate the distance between two locations, we use the 
length of a geodesic, i.e., the shortest path between two 
points on the surface of the ellipsoidal earth [34]. 


7.1 Path Tracking 


We compare reported OF locations with GPS traces 
that we record with the tracked device. We conduct ex- 
periments with different means of transportations in and 
around a metropolitan area. We measure the error of the 
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Table 5. Evaluation scenarios including distance traveled and 
duration of recorded GPS traces, and the number of downloaded 
OF location reports. 


Scenario Distance (m) Duration (h:m:s) No. OF reports 
Walking 3375 0:55:11 489 
Restaurant 160 0:42:29 185 
Train 23237 0:35:30 166 
Car 94569 1:04:22 25 


raw OF reports to the GPS trace and show that we can 
significantly improve accuracy by applying a scatterplot 
smoothing algorithm to the raw reports. 


7.1.1 Experimental Setup 


We conduct experiments in different scenarios that at- 
tempt to emulate common mobility patterns: walking, 
driving a car, riding a train, and visiting a restaurant. 
All experiments were conducted in and around the city 
of Frankfurt am Main, Germany. For each scenario, we 
record a GPS trace that serves as the ground truth for 
our evaluation.® 

Table 5 summarizes the evaluated scenarios with 
the time and distance traveled according to the GPS 
trace and the number of uploaded OF reports during 
these times. Our test devices are an iPhone 8 running 
iOS 13.5 and a MacBook Pro running macOS 10.15.4 
that are logged into the same iCloud account. During 
each experiment, we carry the iPhone in flight mode to 
emit OF advertisements and record the GPS trace us- 
ing the SensorLog [49] application set to a 2s sampling 
interval. The MacBook acts as the owner device that 
we use to download location reports after each experi- 
ment. We did not carry any other Apple devices during 
an experiment, so we would not get additional reports. 
Consequently, all downloaded reports were submitted 
by the devices of pedestrians. To access the private ad- 
vertising keys for downloading and decrypting location 
reports, we use our PoC implementation (cf. § 10). We 
use the OF reports’ generation timestamps to filter the 
reports that lie between the start and end date of each 
GPS trace. 


5 The experiments were conducted during the COVID-19 pan- 
demic. Consequently, the authors implemented anti-infection 
measures, i.e., they wore face masks, used hand sanitizer while 
traveling with public transport and exercised minimum phys- 
ical distancing. At the time of the experiments, the local inci- 
dence rate was low (five cases per 100000 inhabitants over seven 
days) [32]. 
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Fig. 4. Map of the walking scenario showing the GPS trace, the 
raw OF location reports, and the estimated path calculated from 
the reports. 


Table 6. Accuracy of OF location reports. 


Mean distance to GPS trace (m) Improvement 





Scenario Reported Raw Est.Path Raw-—>Est. Path 
Walking 121.9 81.4 25.9 3.1x 
Restaurant 117.2 60.2 27.4 2.2x 
Train 171.0 440.7 299.6 1.5x 
Car 145.2 580.7 — — 


7.1.2 Raw Location Report Accuracy 


We calculate the distance of the OF reports to the GPS 
trace. As GPS trace and OF reports do not have a com- 
mon time index, we interpolate the GPS trace to the 
time indices of the OF reports. Then, we calculate the 
distance of each OF report to the corresponding point 
on the interpolated GPS trace. Table 6 shows the mean 
error of the raw reports. We can see that raw reports 
have a mean error in the order of 100m for the walking 
and restaurant scenarios. However, results become less 
accurate when using faster modes of transportations, 
e.g., 500m when riding a train. Table 6 also shows the 
reported accuracy value, which is part of the OF reports 
(cf. § 6.3), and the improved results of the estimated 
path that we will discuss next. 


7.1.3 Estimated Path Accuracy 


The raw location reports provide a decent accuracy suf- 
ficient to pinpoint an individual’s location to a city dis- 
trict or even a street. However, when plotting the lo- 
cations on a map (cf. Fig. 4), we see that simply “con- 
necting the dots” does not yield a smooth path that we 
would expect from a human mobility trace. We won- 
dered if we could improve accuracy by harnessing and 
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combining all finders’ reports. Essentially, we want to 
provide a better estimate of the actual path by fitting a 
curve through the reported OF locations. 

To this end, we apply a popular curve fitting 
method called locally weighted scatterplot smoothing 
(LOWESS) [22] independently to the longitude and lat- 
itude coordinates of the location reports. LOWESS per- 
forms a weighted local (or moving) regression over a 
window of nearby data points. A Gaussian distribution 
assigns a higher weight to the data points in the cen- 
ter of the window. The size of the window heavily in- 
fluences the performance of LOWESS. Empirically, we 
found that a value of 30 reports provides the most ac- 
curate results for our traces. 

Fig. 4 shows such an estimated path calculated from 
the walking scenario. The figure shows that our path 
estimation algorithm approximates the real path rather 
well. We quantify the accuracy of the estimated path 
by calculating the mean distance to the GPS track and 
show the results in Tab. 6. Most OF locations were 
reported in busy places in a metropolitan city (walk- 
ing and restaurant visit). Here, our fitting algorithm 
approximated the real path with a mean error below 
30 m—a 3.1x improvement over the raw data. Our fit- 
ting algorithm is unable to produce meaningful results 
for the car experiment as the sample set is too sparse. 
For completeness, we include maps of the restaurant, 
train, and car scenario in Appendix C. 

Overall, using a fitting algorithm helps to recon- 
struct the user’s path from noisy OF reports if the 
dataset is dense enough. In the best case, we improved 
the accuracy compared to the raw location reports by a 
factor of 3.1x. 


7.2 Identifying Top Locations 


Apple’s servers store OF reports for seven days, which 
can be accessed by an unauthorized third-party appli- 
cation (cf. § 10). Previous work has shown that the top 
(most visited) locations can be used for user fingerprint- 
ing. Montjoye et al. [38] demonstrated that four spatio- 
temporal points are sufficient to identify 95% of all in- 
dividuals in an anonymized location dataset. Also, Zang 
and Bolot [52] found that the three top locations on a 
mobile cell-level are accurate enough to identify 50% of 
all individuals in a large data set. Even though most 
devices try to keep a permanent connection to the In- 
ternet, our analysis has shown that hundreds of reports 
have been generated throughout a week. This section 
shows that OF reports can also be used to determine 


top locations and even achieve an accuracy of up to 
5m. 


7.2.1 Experimental Setup 


To determine the top locations, we want to use the same 
seven-day historic data available as an attacker getting 
access to the OF report decryption keys (cf. § 10). Col- 
lecting this data from various test subjects for an eval- 
uation would be extremely intrusive to their privacy. 
Running our evaluation algorithm on the subjects’ Macs 
would also not be feasible, because the subjects would 
have to disable macO$’s SIP to download raw OF loca- 
tion reports, effectively weakening their system security. 
Sensibly, our ethical review board (ERB) would not ap- 
prove such a study. Consequently, we abstain from con- 
ducting a user study and, instead, use our (the authors’) 
data for the evaluation. To preserve the authors’ privacy, 
we will not show or discuss the raw data. Instead, we 
apply our algorithm for identifying top locations on the 
raw data and then discuss the output. 


7.2.2 Resampling and Clustering OF Reports 


Previous works [38, 52] have used identifiers of cell sites 
to rank top locations. For a particular user, they sim- 
ply count the number of registrations per cell and base 
the location rank on this number. E.g., the cell with the 
highest registration count is regarded as the top 1 loca- 
tion. We cannot apply the same concept for identifying 
top locations based on OF reports for two reasons. 

Problem 1: Non-Uniform Distribution Over Time. 
We observed that the density of OF reports over time is 
non-uniform. In busy places such as malls or restau- 
rants, more finder devices are available and, conse- 
quently, more reports are generated. If we simply count 
the number of OF reports to determine the top loca- 
tions, these busy places are likely to be overrepresented. 
Instead, we want to rank top locations based on the 
overall visit duration of the user. 

Problem 2: Continuous Coordinate Range. Cell 
identifiers are elements of a discrete set. In contrast, 
the location coordinates in OF reports are drawn from 
a continuous range, which makes simple counting of vis- 
its per location hard. To address both issues, we use a 
two-step approach. 

Solution 1: Resampling. We resample the location 
reports on the time axis to solve Problem 1 and “flat- 
ten” the distribution over time. Within each resampling 
interval R, we calculate the center coordinates as the 
mean of all reports within that interval. Setting a rea- 
sonable value R is essential. If R is too small, the desired 
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Table 7. Identified top locations sorted by their rank. Error in- 
dicates the geodesic distance between the ground truth and the 
estimated cluster center. Days indicate on how many days of the 
week the location was visted. Dwell time is the estimated overall 
time that the location was visited. 


Kind Rank Error Resampled Days Dwell time 

reports (hour:min) 
Home 1 14.1m 129 6 43:00 
Work 2 4.9m 25 2 08:20 
Partner 3 15.5m 19 2 06:20 
Friends 4 11.1m 15 1 05:00 
Sport 5 9.5m 9 3 03:00 
Family 6 6.6m 9 2 03:00 


flattening effect will not occur. If R is too large, we lose 
accuracy. Empirically, we found that R = 20min pro- 
duces good results for our dataset. 

Solution 2: Clustering. We use a clustering algo- 
rithm to identify places for which we received multiple 
location reports over time to solve Problem 2. In partic- 
ular, we select the popular Density-Based Spatial Clus- 
tering of Applications with Noise (DBSCAN) [26, 43] 
algorithm. DBSCAN can detect an arbitrary number of 
clusters, which is important for us as we do not know 
the number of top locations a priori. Also, DBSCAN 
adequately deals with noise, which is common in OF 
reports. In short, DBSCAN forms clusters by finding 
“core samples” that have at least N neighbors within 
a radius of D. All samples that are not part of a clus- 
ter are considered as noise. Empirically, we determined 
that D = 50m and N = 6 produces good results for our 
dataset. 


7.2.3 Results 


We run our resampling and clustering algorithms on an 
author dataset. Together, the algorithms determine a 
list of six clusters that we interpret as top locations. Af- 
terwards, we let the author label each entry and assign 
the actual location of the home or office by picking co- 
ordinates from an online map service, which we use as 
ground truth. Finally, we compute the distance of the 
clusters’ centers to the ground truth locations and show 
the complete results in Tab. 7. The results demonstrate 
that we successfully identified typical locations such as 
home and workplace [52] with an error below 20m. Im- 
pressively, the location reports were precise enough to 
pinpoint not only the workplace but with a 5m error 
even identify the exact office. 

We wondered if it would have been possible to dis- 
cern the type of location (e.g., home or work) just from 
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Fig. 5. Visiting times distribution of top locations averaged over 
seven days. Darker colors indicate a higher number of location 
reports during these hours. 


the characteristics of the location reports. To this end, 
we provide a detailed view of the visiting times across 
the hours of a day in Fig. 5. The figure shows the hours 
of a day in which location reports were submitted for 
the respective top location. We can visually identify the 
type of some locations from this distribution. In partic- 
ular, the workplace distribution matches typical office 
hours (8am to 5pm). The all-day distribution of the 
home location reflects the fact that the measurements 
were taken over the course of a week and the author 
stayed at home on some days for remote work. 
Previous work showed that four spatio-temporal 
points could be sufficient to uniquely identify an in- 
dividual with a chance of 95% [38]. While we were 
unable to conduct a similar large-scale user study as 
in [38] based on OF, our small-scale experiment already 
demonstrates that OF reports contain highly sensitive 
information that can be used to deanonymize users. 


8 Security and Privacy Analysis 


In this section, we perform a security and privacy anal- 
ysis of Apple’s OF system implemented on iOS and 
macOS based on the adversary models described in 
§ 4. We first examine the cryptography-related compo- 
nents that are relevant for the local application (A1) 
and service operator (A4) models that have access to 
keys and encrypted reports, respectively. Then, we as- 
sess the BLE interface relevant to the proximity-based 
adversary (A2) and the HTTPS-based server commu- 
nication relevant for the network-based adversary (A3). 
We summarize our findings in Tab. 8 and discuss in the 
following. 


8.1 Cryptography 


Key Diversification. OF employs key diversification 
to derive the rolling advertisement keys from the mas- 


ter beacon key (cf. § 6.1). Apple’s design follows the 
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Table 8. Summary of our security and privacy analysis of OF. We list potential issues and provide a short assessment about whether or 


not they are exploitable in practice (Wor X) and if /, by which adversary model (cf. § 4). 


The custom key diversification process follows the NIST recommendation for key 
derivation through extraction-then-expansion [16]. 

Use of NIST P-224 is discouraged by some cryptographers [18]. However, we are 
unaware of any practical attacks against P-224 when used exclusively for ECDH. 
Keychains and SEP are used to securely store keys for server communication and 
the master beacon key. However, macOS caches the derived advertisement keys on 
disk, which can be read by local applications. Attackers can exploit this to access 
(historical) geolocation data as we describe in § 10. 


BLE payload and address are determined by the advertisement key, which is changed 
at 15 min intervals, making long-term tracking hard. 

As OF uses non-connectable mode to emit advertisements, devices remain secure 
against RCE attacks on the Bluetooth firmware [42]. 

An attacker could emit/relay legitimate advertisements at other physical locations 
to pollute the set of location reports. 


Impact similar to Bluetooth relaying. However, we have been unable to inject fabri- 
cated location reports into the server communication. 
Spoofing an owner device is not critical as location reports are end-to-end encrypted. 


Component Potential issue Exploit. | Assessment 
Cryptography Key diversification x 
Choice of P-224 curve x 
Insecure key storage Vv (Al) 
Bluetooth Device tracking via x 
BLE advertisements 
Remote code execu- x 
tion (RCE) 
Denial-of-service Vv (A2) 
(DoS) 
Server comm. Spoofing (finder) x 
Spoofing (owner) x 
Device identification v (A4) 


Apple's servers can identify both finder and owner devices. This enables a location 


correlation attack that we discuss in § 9. 


NIST recommendation of performing extraction-then- 
expansion [16] to securely derive keys. The two-step pro- 
cess first extracts a derivation key from a secure input 
and then expands this key to the desired output length. 
Specifically, OF first extracts a new 32-byte key SK; 
from the previous derivation key using the KDF and 
then expands SK; using the same KDF to 72 bytes. 

Choice of NIST P-224 Curve. We believe that Ap- 
ple’s choice for the NIST P-224 curve is the consequence 
of the constrained capacity of BLE advertisements while 
maximizing the security level of the encryption keys. 
Apple’s implementation of P-224 in corecrypto has been 
submitted to validate compliance with U.S. Federal In- 
formation Processing Standards (FIPS) [9]. Within the 
cryptography community, some researchers discourage 
the use of P-224 because its generation process is un- 
clear [17, 18]. More modern curves with the same secu- 
rity margin are available, e.g., M-221 [13], but are not 
used by Apple. 

Insecure Key Storage. We analyzed how OF keys 
and secrets are stored on the system. While most in- 
volved keys are synchronized and stored in the iCloud 
keychain, we discovered that the advertisement keys de- 
rived from the master beacon key (cf. § 6.1) are cached 
on disk to avoid unnecessary re-computations. We found 
that the cached key directory is accessible by a local ap- 
plication with user privileges and can be used to bypass 
the system’s location API, as we describe in § 10. 


8.2 Bluetooth 


Device Tracking. One of the key design goals of OF 
is to prevent tracking of lost devices via their BLE ad- 
vertisements. According to our analysis, OF fulfills this 
promise by randomizing both BLE advertisement ad- 
dress and payload in 15 min intervals (cf. § 6.2). 

Remote Code Execution. In addition, OF uses the 
so-called “non-connectable mode” [19, Vol. 3, Part C, 
§ 9.3.2], which means that other devices cannot connect 
to it and exploit potential remote code execution (RCE) 
vulnerabilities in the Bluetooth firmware [42]. 

Denial-of-Service Through Relaying. BLE adver- 
tisements only contain the public part of an advertise- 
ment key and are not authenticated. Anyone recording 
an advertisement can replay it at a different physical 
location. Any finder at that location would generate a 
location report and submit it to Apple. Through this 
type of relaying, an attacker could make a lost device ap- 
pear at a different location, effectively mounting a DoS 
attack as owners would receive different contradicting 
location reports. 


8.3 Server Communication 


Spoofing. The communication with Apple’s servers uses 
TLS, including certificate pinning to ensure that no 
MitM attack can be deployed. Based on our analysis, 
the protocol seems to implement a secure authentication 
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scheme. However, we have been unable to reconstruct 
some of the involved components. We understand that a 
device-specific certificate (cf. § 6.3) and a private signing 
key, protected by the SEP, are involved in submitting 
reports. We assume that this private key is used for 
remote attestation to prevent non-Apple devices from 
submitting potentially fabricated reports. The genera- 
tion and registration process of these keys with Apple’s 
server remains unknown to us. Also, the “anisette data” 
used for authenticating owner devices (cf. § 6.4) is not 
publicly documented, and the code that generates the 
tokens is highly obfuscated. 
Device Identification. 
the exact details of the authentication mechanism, we 


While we did not recover 


have observed that both finder and owner devices pro- 
vide identifiable tokens to Apple’s servers. In particular, 
owner devices provide their Apple ID to access location 
reports. In § 9, we show that by requesting IDs, Apple’s 
servers are—in principle—able to correlate the locations 
of different owners. 


9 Apple Can Correlate User 
Locations 


Apple as the service provider (A4) could infer that two 
or more owners have been in close proximity to each 
other as OF uses identifiable information in both up- 
load and download requests. Law enforcement agencies 
could exploit this issue to deanonymize participants of 
(political) demonstrations even when participants put 
their phones in flight mode. Exploiting this design vul- 
nerability requires that the victims request the location 
of their devices via the Find My application.® Next, we 
describe the vulnerability, a possible attack, and our 
proposed mitigation. 


9.1 Vulnerability 


When uploading and downloading location reports, 
finder and owner devices reveal their identity to Ap- 
ple. During the upload process, the finder reveals a 
device-specific identifier in the HTTPS request header 
(cf. Tab. 3) that can be used to link multiple reports to 


6 This requirement currently limits the exploitability of 
the described vulnerability. However, exploitability could in- 
crease when changing the usage pattern of the downloading 
API (cf. § 6.4). For example, a future Apple application could 
notify users about lost devices automatically by regularly re- 
questing reports for the devices’ last known locations, thereby, 
removing the need for user interaction. 
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Fig. 6. Apple could infer which users have been in close proximity 
to each other. 


the same finder. Similarly, during the download process, 
the owner device has to reveal its Apple ID. In partic- 
ular, the owner includes its Apple ID in the HTTPS 
request headers (cf. Tab. 4), which allows Apple to link 
reports uploaded by a particular finder to the Apple ID 
of the downloading owners. Since we do not have access 
to Apple’s servers, we cannot make assumptions about 
whether or not Apple actually stores such metadata. 
However, the fact that Apple could store this informa- 
tion indefinitely opens the possibility of abuse. 


9.2 Attack 


It is possible for Apple to find out which owners have 
been in physical proximity to each other if the owners 
request the location of their devices via the Find My ap- 
plication. We sketch the attack for two owners in Fig. 6. 
A finder F' receives advertisements from the lost devices 
Ly, and Lz that belong to the owners O; and Og, respec- 
tively, and publishes encrypted location reports to Ap- 
ple’s servers. Due to the limited communication range 
of BLE, we can reasonably assume that DL, and D2 have 
been in close proximity if the respective location reports 
were generated at a similar time and submitted by the 
same finder. Later, O; and Og both download location 
reports, by opening the Find My app, for Ly and Lz, 
respectively. At this point, Apple can infer that these 
two owners identified by their Apple IDs were close to 
each other. 


9.3 Impact 


The presented attack could be harmful to protesters 
who put their phones into flight mode to stay anony- 
mous and prevent their devices from showing up during 
a cell site analysis—which is precisely when the devices 
would start emitting OF advertisements. Law enforce- 
ment agencies could record all the advertised public keys 
at the demonstration site and ask Apple to provide the 


Who Can Find My Devices? Security and Privacy of Apple’s Crowd-Sourced Bluetooth Location Tracking System =——= 14 


Apple IDs of the users that later requested location re- 
ports to deanonymize the participants. Such a collusion 
would be a combination of the proximity-based (A2) 
and service provider (A4) adversary models (cf. § 4). 


9.4 Proposed Mitigation 


There are two straightforward options to mitigate this 
attack: remove identifying information from either (1) 
finder devices or (2) owner devices. We assume that the 
authentication of the finder provides a form a remote 
attestation proving that the device is—in fact—a gen- 
uine Apple device allowed to upload location reports to 
Apple’s servers. In that case, option (1) is not feasible as 
the finder has to provide some verifiable information by 
design. However, we currently see no reason why owner 
devices have to authenticate to Apple’s servers and pro- 
vide personally identifiable information, i.e., the Apple 
ID. We found that any Apple device can request ar- 
bitrary location reports, so the authentication appears 
to be a security-by-obscurity measure and only prevents 
everyone without access to an Apple device from access- 
ing location reports. Therefore, we recommend option 
(2) as mitigation and disable authentication for down- 
load requests. 


10 Unauthorized Access of 
Location History 


We discovered a vulnerability of the OF implementa- 
tion on macO$ that allows a malicious application (A1) 
to effectively circumvent Apple’s restricted location 
API [5] and access the geolocation of all owner devices 
without user consent. Moreover, historical location re- 
ports can be abused to generate a unique mobility pro- 
file and identify the user, as we demonstrate in § 7. 


10.1 Vulnerability 


§ 6 describes that the location privacy of lost devices 
is based on the assumption that the private part of 
the advertisement keys is only known to the owner de- 
vices. The advertisement keys change every 15 minutes 
and OF supports retrieving location reports from the 
last seven days, so there is a total of 672 advertise- 
ment keys per device, for which there exist potential 
location reports on Apple’s servers. In principle, all of 
these keys could be generated from the master beacon 
key (cf. § 6.1) whenever needed. However, Apple de- 
cided to cache the advertisement keys, most likely for 
performance reasons. During our reverse engineering ef- 
forts, we found that macOS stores these cached keys on 
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Fig. 7. Attack flow for gaining access to the victim’s location 
history. Attacker-controlled components are marked in red. 


disk in the directory /private/var/folders/<Random> 
/com.apple.icloud.searchpartyd/Keys/<Deviceld> 
/Primary/<IdRange>.keys. The directory is readable 
by the local user and—in extension—by any application 
that runs with user privileges. On iOS, those cache files 
exist as well, but they are inaccessible for third-party 
applications due to iOS’s sandboxing mechanism. 


10.2 Attack 


We describe the attack flow and explain our PoC imple- 
mentation, which leads to the attacker gaining access 
to the location history of the victim’s devices. In the 
following, we detail the operation of our two-part PoC 
attack. The steps are referring to Fig. 7. 

Reading Private Keys (Steps 1-3). 
installs a non-sandboxed malicious application.’ When 


The victim 


started, the malicious application runs with user priv- 
ileges and, therefore, has access to the key cache di- 
rectory. It can read the advertisement keys from disk 
(2) and then exfiltrate them to the attacker’s server 
(3). Apart from starting the application, this process 
requires no user interaction, i.e., no dialogs requesting 
disk access are displayed to the user. 





7 Sandboxing is only required for applications distributed via 
Apple’s app store. Many popular macOS applications such as 
Firefox or Zoom are not distributed via the app store and, thus, 
could have exploited the discovered vulnerability. 
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Downloading Location Reports (Step 4). The at- 
tacker’s machine essentially acts as an owner device 
(cf. § 6.4) but uses the victim’s keys as input for the 
HTTPS download request. To download the victim’s lo- 
cation reports, our PoC needs to access the attacker’s 
anisette data for authenticating the request to Apple’s 
servers. As we need to link private frameworks and ac- 
cess the anisette data in our implementation, the at- 
tacker’s macOS system needs to disable SIP and Ap- 
ple mobile file integrity (AMF). Since this device is 
attacker-owned, this requirement does not limit the ap- 
plicability of the presented attack. SIP and AMFI are 
disabled by booting in the macOS recovery mode and 
running the following terminal commands. 


csrutil disable 
nvram boot-args="amfi_get_out_of_my_way=1" 


Decrypting Location Reports (Step 5). In the fi- 
nal step, the adversary uses the victim’s private keys to 
decrypt the location reports. 


10.3 Impact 


The attack essentially allows any third-party applica- 
tion to bypass Apple’s Core Location API [5] that en- 
forces user consent before an application can access the 
device’s location. Moreover, the attacker can access the 
location history of the past seven days of all the owner’s 
devices. The victim is only required to download and 
run the application but remains otherwise clueless about 
the breach. Our analysis has shown that the advertise- 
ment keys are precomputed for up to nine weeks into the 
future, which allows an adversary to continue download- 
ing new reports even after the victim has uninstalled the 
malicious application. 

Even though the location reports are not continu- 
ous, our evaluation in § 7 shows that it is easy to identify 
the user’s most visited places such as home and work- 
place. Furthermore, we show that the decrypted location 
reports can accurately track the victim’s movement of 
the last seven days. 


10.4 Mitigation 


As ashort-term mitigation, users can disable participat- 
ing in the OF network to prevent the attack. In addi- 
tion, we propose three long-term solutions to mitigate 
the attack: (1) encrypting all cached files on disk store 
the decryption key in the keychain, (2) restricting access 
to the cache directory via access control lists, (3) not 
caching the keys and computing them on-demand. In 
fact, macOS 10.15.7 includes a mitigation based on op- 


tion (2), which moved the keys to a new directory that 
is protected via the system’s sandboxing mechanism. 


11 Related Work 


We review other crowd-sourced location tracking sys- 
tems and previous security and privacy analyses of Ap- 
ple’s ecosystem. 

Crowd-Sourced Location Tracking. Weller et al. 
[51] have studied the security and privacy of commer- 
cial Bluetooth tags (similar to Apple’s definition of ac- 
cessories) sold by multiple vendors. Many of the studied 
systems provide crowd-sourced location tracking similar 
to Apple’s OF, allowing users to discover lost devices by 
leveraging the finder capabilities of other devices. The 
study discovered several design and implementation is- 
sues, including but not limited to the use of plaintext lo- 
cation reports, unauthorized access to location reports, 
broken TLS implementations, and leaking user data. 
Based on their findings, Weller et al. [51] propose a novel 
privacy-preserving crowd-sourced location tracking sys- 
tem called PrivateFind. PrivateFind does not need user 
accounts and uses end-to-end encrypted location reports 
with a symmetric encryption key stored on the Blue- 
tooth finder during the initial setup. In their solution, 
a finder that discovers a lost Bluetooth tag sends its 
geolocation to the finder over Bluetooth. The lost de- 
vice encrypts the location with its symmetric key and 
returns the encrypted report. The finder then uploads 
the encrypted location report on behalf of the tag. An 
owner device that knows the symmetric key can then 
download and decrypt the location report. 

To the best of our knowledge, PrivateFind is the 
only other privacy-friendly offline device finding system 
next to OF. Both designs achieve similar privacy goals, 
such as preventing a third party from learning the loca- 
tion. The main difference is the way encrypted location 
reports are generated. OF employs public-key cryptog- 
raphy, which allows finder devices to generate a loca- 
tion report upon receiving a single Bluetooth advertise- 
ment. In PrivateFind, lost devices are actively involved 
in the generation, which leads to the following prac- 
tical issues: (1) Lost devices or tags drain their bat- 
teries quicker as they have to establish Bluetooth con- 
nections with other devices and perform cryptographic 
operations. This opens up the door for resource-exhaus- 
tion attacks where a powerful adversary issues an exces- 
sive number of encryption requests to the lost devices. 
(2) The lack of finder attestation would allow an at- 
tacker to upload fabricated reports as the lost device 
cannot verify the correctness of the provided location. 
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Apple’s Wireless Ecosystem Security and Privacy. 
Previous work analyzed parts of Apple’s wireless ser- 
vices. Bai et al. [15] investigated the risks of using inse- 
cure multicast DNS (mDNS) service advertisements and 
showed that they have been able to spoof an AirDrop 
receiver identity to get unauthorized access to personal 
files. Stute, Kreitschmann, and Hollick [46] and Stute 
et al. [48] reverse engineered the complete AWDL and 
AirDrop protocols and demonstrated several attacks, 
including user tracking via AWDL, a DoS attack on 
AWDL, and a MitM attack on AirDrop. Martin et al. 
[36] extensively analyzed the content of the BLE adver- 
tisements for several Apple services. They found sev- 
eral privacy-compromising issues, including device fin- 
gerprinting and long-term device and activity tracking. 
Celosia and Cunche [21] extended this work and discov- 
ered new ways of tracking BLE devices such as Apple 
AirPods and demonstrated how to recover user email 
addresses and phone numbers from BLE advertisements 
sent by Apple’s Wi-Fi Password Sharing (PWS). Hein- 
rich et al. [30] found that AirDrop also leaks user phone 
numbers and email addresses and proposes a new pro- 
tocol based on private set intersection. Stute et al. [45] 
investigated the protocols involved in PWS and Apple’s 
Handoff and found vulnerabilities allowing device track- 
ing via Handoff advertisements, a MitM attack on PWS, 
and DoS attacks on both services. While the above 
works have analyzed other services, we leveraged their 
methodology for approaching our analysis and reverse 
engineering work of OF. 


12 Conclusion 


Apple has turned its mobile ecosystem into a massive 
crowd-sourced location tracking system called OF. In 
this system, all iPhones act as so-called finder devices 
that report the location of lost devices to their respec- 
tive owners. Apple claims to implement OF in a privacy- 
preserving manner. In particular, location reports are 
inaccessible to Apple, finder identities are concealed, 
and BLE advertisements cannot be used to track the 
owner [35]. We have been the first to challenge these 
claims and provide a comprehensive security and pri- 
vacy analysis of OF. 

The good news is that we were unable to falsify 
Apple’s specific claims. However, we have found that 
OF provides a critical attack surface that seems to have 
been outside of Apple’s threat model. Firstly, the OF 
implementation on macOS allows a malicious appli- 
cation to effectively bypass Apple’s location API and 
retrieve the user’s location without their consent. By 


leveraging the historical reports, an attacker is able to 
identify the user’s most visited location with sub-20m 
accuracy. Secondly, we believe that Apple has yet to 
provide a good reason why owner devices need to au- 
thenticate when retrieving encrypted location reports 
as it allows Apple to correlate the locations of different 
Apple users. 

We were only able to publish our findings by inten- 
sively studying the OF system using reverse engineering, 
which is a very time-consuming process (we started ana- 
lyzing OF mid-2019). To protect user privacy, we believe 
that systems handling highly sensitive information such 
as OF need to be openly and fully specified to facilitate 
timely independent analyses. To this end, we urge man- 
ufacturers to provide not only partial [6] but complete 
documentation of their systems and release components 
as open-source software whenever possible, which is al- 
ready a best practice for cryptographic libraries [9]. 


Responsible Disclosure 


We disclosed the vulnerability in § 10 on July 2, 
2020. On October 5, 2020, Apple informed us that 
macOS 10.15.7 provides a mitigation for the issue, which 
was assigned CVE-2020-9986. In addition, we informed 
Apple about the vulnerability in § 9 on October 16, 
2020, and are currently waiting for feedback. 


Availability 


We release the following open-source software artifacts 
as part of the Open Wireless Link project [47]: (1) The 
PoC implementation that can download and decrypt 
location reports, which we used for the exploit de- 
scribed in § 10 (github.com/seemoo-lab/openhaystack). 
(2) The 
scripts to 


raw data and_= evalua- 
the in § 7 


(github.com/seemoo-lab/offline-finding-evaluation). 


experimental 


tion reproduce results 
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A HTTP Body Content 


Listings 1 and 2 show the HTTP request and response 


body for downloading location reports, respectively. 


Listing 1. Request body for downloading location reports. 


{ 


"search": [ 
{ 
"endDate": 1599052814928, 
"startDate": 1598965514928, 
Midis thes cL 


"tEJGnij59g+mgj7cKhDMYN3UMNb8...", 
"sr74jRoVkhXdshfOY68j6qGyW68v...", 
"pzcyP8dXfdSyVTHK8io7AUgAx85J...", 
eel 

Jin diated 


Listing 2. Response body for downloading location reports. 


{ 


"results": [ 
{ 
"datePublished": 1586804587284, 
"payload": "JETtmwIEzRBG....", 
"description": "found", 
"id": "B6E5tpUPbuudAc..." 
"statusCode": 0 
Fy gad 
"statusCode": "200" 


B 


Reporting Delay 


Fig. 8 shows the distribution of the reporting delays 


(time between uploading and generating a report) over 


all traces recorded for the experiments in § 7.1. 


C Additional Experimental Traces 


We show the reports of our restaurant, train, and car 


evaluation scenarios in Figs. 9 to 11, respectively. 
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cumulative distribution function. and the estimated paths for the restaurant scenario (cf. § 7.1). 
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Fig. 10. Map showing the GPS trace, the raw OF location reports, and the estimated paths for the train scenario (cf. § 7.1). 


Raw OF reports 


—— GPS trace 





Fig. 11. Map showing the GPS trace and the raw OF location reports for the car scenario (cf. § 7.1). 


